# Refunds a Single Transaction or Frequent Transaction

Each method has a specific time window during which a refund can be issued. Once this period expires, refunds can no longer be processed via the API for that payment.
### Refund Deadlines by Payment Method
| Payment Method | Maximum Refund Time |
|  --- | --- |
| MB WAY | 12 months |
| Visa & Mastercard | 12 months |
| Apple Pay | 12 months |
| Google Pay | 12 months |
| Samsung Pay | 12 months |
| MB SPG references | 120 days |
| Other MB references | No limit |
| Direct Debit | 180 days |

**Required scope:** <code style="background:#e8f0fe;color:#1a73e8;padding:2px 8px;border-radius:12px;font-size:0.85em">refund:create</code>

Endpoint: POST /refund/{id}
Version: 2.0
Security: accountId, apiKey

## Path parameters:

  - `id` (string, required)
    The capture uuid associated with Single or Frequent Transaction

## Request fields (application/json):

  - `transaction_key` (string)
    Your internal key identifying this refund

  - `iban` (string)
    Optional - Iban from the bank account

  - `email` (string)
    Optional - Email from the bank account holder

  - `phone` (string)
    Optional - Phone from the bank account holder

  - `account_holder` (string)
    Optional - Bank account holder name

  - `value` (number, required)
    The amount to refund. When `revert` is present, this is the gross amount from the payer's perspective — the amount refunded to the payment method plus any redeemed reward credits being restored.
    Example: 17.5

  - `revert` (object)
    Reverts refers to the process of reversing a previously made split payment. This means that the amounts that were divided and allocated to different recipients or accounts are returned to the original payer or redistributed as per the new instructions.

  - `revert.mode` (string)
    - **TOTAL:** All associated splits and their margins will be reverted - **PARTIAL:** Only the selected splits and their margins will be reverted
    Enum: "partial", "total"

  - `revert.reward_redemption_reversal` (number)
    The portion of the refund value to restore to the customer's reward balance instead of refunding it to the payment method — the payment method receives the refund value minus this amount. Only valid when the capture redeemed reward credits, and it can exceed neither the refund value nor the redemption not yet restored by previous refunds. On a TOTAL revert it must equal the remaining redemption, and defaults to it when omitted; on captures fully paid with reward credits it defaults to the refund value. Otherwise, omitting the field restores nothing. The restored credit lands on the customer's reward ledger as a `REWARD_RESTORATION` entry on `GET /customer/{id}/rewards`. See the [Rewards & Redemptions guide](/docs/guides/rewards-and-redemptions) for the full flow.
    Example: 2.5

  - `revert.splits` (array)
    Array of splits to revert. Required only if the mode is PARTIAL.

  - `revert.splits.id` (string)
    The uuid of split.

## Response 201 fields (application/json):

  - `status` (string)
    Example: ok

  - `message` (string)
    Example: Your request was successfully created

  - `id` (string)
    A unique identifier for the resource. While typically formatted as a UUID (Universally Unique Identifier), it can also be in other formats as defined by the user. This field ensures the resource can be distinctly recognized and referenced.
    Example: 25997c28-1902-4f6d-842e-c6050e7d5421

## Response 400 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 403 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 404 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 412 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 422 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 429 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 500 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

